昨天我們寫了和會員相關的API文件，也請 Curso 幫我們實作出來。不過就算AI幫我們把 Code生成出來了，但我們還是要花時間確定他是不是對的。

如果本來就會寫程式的人，是幫我們先寫好了，確認後再修改。不會寫的，至少先有東西了。

確認功能

我們使用 postman 來打 api 確定是否是我們需要的功能。

註冊

註冊看起來是沒問題，可以成功註冊。

登入

登入也沒問題，也會把 Token回傳給我們。

取得使用者資訊

path 是 /users/:userId ，把 id放在後面，路徑看起來是沒問題。但是直接打會是沒有授權的錯誤。

這時候就要把剛剛登入後回傳的 token 傳過去進去。那要怎麼傳呢？因為我們使用 Bearer Token 的方式認證，需要把 token 帶到 Header裡面。

在 Postman 選擇 Auth，Auth type選 Bearer Token。然後把 Token放進去就可以了

但是打進去會是錯誤，看起來是伺服器(BE)的錯誤。通常這種錯誤，應該是後端寫錯了之類的。

我們看一下BE的 User Controller，你會發現在他查詢資料的時候，雖然我們打進去給的資料是 userId，但是用來去資料庫找資料的是 username。這意味著其實我們路徑的 /users/:userId 其實是要打 username 。

恩，滿無言的。

  @UseGuards(AuthGuard('jwt'))
  @Get(':userId')
  async getUserInfo(@Param('userId') userId: string): Promise<User> {
    const user = await this.authService.validateUser({ username: userId });
    if (!user) {
      throw new Error('授權失敗，請重新登入。');
    }
    return user;
  }

我們把 /users/:userId 後面的 userId 改成 username試試看。欸就成功了。

[!NOTE]
Bearer Token 是一種用於身份驗證的安全憑證，通常被用在 API 和後端系統的通訊中。在這種機制下，當用戶成功登入或獲得授權後，伺服器會簽發一個 token（通常是 JWT），這個 token 會附帶在後續的請求中來證明用戶的身份。

當應用程式發送 API 請求時，Bearer Token 通常被放在 HTTP 請求的 Authorization 標頭中，以以下的格式：

Authorization: Bearer [token] 

修改資訊

修改的其實路徑和 取得資訊 是一樣的，差在網路方法，取得的話是用 GET，修改資訊是用 PUT。那問題其實是一樣的，就是把路徑的 userId 改成 username 就可以成功了。

結語

雖然使用AI生成很快，但AI不保證都是對的。會需要花時間去確認是否正確。但是如果不對的話，還是要有能力可以修改。或是要很有耐心和AI溝通。但其實AI很常鬼打牆🤣，需要巨大的耐心。